Service-oriented architecture (SOA) is a software design and software architecture design pattern based on structured collections of discrete computing components or software modules, known as services, that collectively provide the functionality of a large software application. The purpose of SOA is to allow an easy cooperation of a large number of computers that are connected over a network, such as the Internet. Every computer can run an arbitrary number of programs, called services in this context, that are built in a way that they can exchange information with one another without the need to make changes to the underlying program itself. In a SOA, resources are made available to participants in the network as independent services that the participants can access in a standardized way. Whereas most definitions of a SOA use SOAP requests conveyed via HTTP or HTTPS over TCP/IP, a SOA may use any web service-based technology. The web services interoperate based on formal definitions which are independent from the underlying platform and programming language. The interface definition encapsulates the specific implementations, so that a SOA is independent of a specific development technology (such as Java and .NET). The software components thus become very reusable because the interface is standards-compliant and is independent from the underlying implementation of the web service logic. In this context, SOA is nowadays one of the preferred architecture paradigms for fulfilling the needs of fast changing business requirements. It provides more agility by splitting monolithic applications into components that can be re-used and orchestrated to get new functionality on demand. New or changed business processes can be implemented by combining existing services or other types of SOA assets. The person skilled in the art will appreciate that SOA is not only popular for implementing business applications/processes, but likewise for implementing complex technical systems, such as the distributed controlling logic of a large assembly line in a factory, or large distributed computing systems which serve for processing large data sets, such as weather forecast models or gene analysis models.
In summary, the implementation of a distributed SOA-based computing system leads to a vast collection of distributed and loosely coupled computing components, such as services. However, the individual computing components are typically developed individually, so that at any given time, the components of a SOA-based system may be in different phases, i.e. one component may already be in productive use, another component may still being tested, and yet another component may be under development. In other words, the individual computing components undergo a series of distinct phases during their lifetime, which is called a “lifecycle”. In this context, lifecycle management, i.e. the controlling of the correct transition of the computing components from one lifecycle state to the next is a complex and difficult task. It goes without saying that if a computing component is set to productive although the necessary tests have not been passed, this could lead to catastrophic consequences, such as the failure of the overall computing system. Managing the lifecycle of services and other SOA assets is thus a critical requirement when governing a Service Oriented Architecture, i.e. when controlling its correct behavior.
Another emerging application area for lifecycle management is API (Application Programming Interface) management. API management enables organizations to publish and promote their APIs in a large scale environment such as the Internet. Since such APIs are typically exposed to a large community of users, managing the lifecycle of API assets is a very important feature of API management solutions.
Lifecycle management is typically performed on metadata stored in a registry, wherein such metadata represents the SOA and/or API assets the lifecycle of which should be managed, i.e. controlled. Due to its importance for the correct operation of the underlying computing system, lifecycle management capabilities are nowadays provided by several existing SOA governance and API management products, e.g., CENTRASITE of applicant, WEBSPHERE Service Registry and Repository (WSRR) of IBM, SYSTINET Registry of HP and Lifecycle Manager of SOA Software. In a SOA registry lifecycles are typically represented with a lifecycle model. A lifecycle model typically comprises lifecycle states that can be assigned to SOA and API assets. The lifecycle states are connected via lifecycle state transitions, which define the allowed state changes an asset can run through. A simple lifecycle model (LCM) 100 is shown in FIG. 1a and comprises the lifecycle states “Under Development” 100a, “In Testing” 100b, “In Production” 100c, and “Retired” 100d. 
Applying this lifecycle model to the managed assets, i.e., computing components such as services, ensures that all assets are in one of the four states. In the example of FIG. 1a, the initial state is “Under Development” 100a from there services can be moved to “In Testing” 100b. Services in the “In Testing” 100b state can either be moved back to “Under Development” 100a or they can be moved to “In Production” 100c. Once services have reached their end of lifetime they can be moved from “In Production” 100c to “Retired” 100d. Complex lifecycle models not only comprise lifecycle states but may also lifecycle stages which in turn comprise a plurality of nested lifecycle states. Lifecycle stages are needed in advanced development environments where SOA assets do not just run through multiple states but also through multiple stages. Hereinafter, it will not be distinguished between state and stage transitions for the sake of simplicity.
To provide a computer-aided management of the lifecycle, policies can be assigned to the transitions of a lifecycle model. Simple policies may define a condition to make sure that an asset can only run through a lifecycle transition if it fulfills one or more requirements. For example, only those services can be moved to “In Production” that are WS-I (Web Services Interoperability) compliant. More advanced policies may not only check conditions, but may also trigger actions. For example, a policy may perform an automatic deployment of a Web service once said Web service is assigned the “In Testing” or “In Production” lifecycle state. This policy can thus be used to annotate the transitions pointing to the “In Testing” and “In Production” states, so that the respective asset is automatically deployed to a testing or production environment.
It is apparent from the foregoing that changing the lifecycle state of assets can have a significant impact on the operation of the underlying computing system. Therefore, dedicated governance, i.e., controlling or management, of the lifecycle transitions is needed. An effective method is to apply approval processes. For example, users and/or groups of users may request a lifecycle transition for a single or a collection of assets. Such a request may raise an approval request to more privileged users or groups such as SOA architects responsible to review all the assets that are entering the “In Production” 100c state. The approving users or approving group can approve or reject the requested transition. In the prior art, approvals are typically defined by attaching approval triggering policies to lifecycle transitions. When such a policy is configured an approval process is triggered once the transition is requested for an asset. The approval process triggered by the approval policies may be simple (such as the sending of an email to the responsive approving user/group) or may comprise a complex process workflow. If the approval process is successful the asset changes its lifecycle state or stage according to the requested transition. If the approval is rejected the asset stays in source state or stage of the requested transition. FIG. 1b shows the exemplary lifecycle model 100 of FIG. 1a with two approval policies controlling the transition from “In Testing” 100b to “In Production” 100c and from “In Production” 100c to “Retired” 100d. 
This prior art approach of allowing to either approve or reject a requested lifecycle state transition is provided already in the existing SOA governance and API management products mentioned further above. Likewise, also the U.S. Pat. No. 7,131,071 B1 titled “Defining an approval process for requests for approval”, which proposes a system for defining an approval process graphically, does not disclose how to integrate approval processes with lifecycle management, in particular not beyond the options to approve or reject an approval request. US patent application 2007/0088585 A1 titled “Capturing the result of an approval process/workflow and declaring it a record” describes how the results of approval processes can be captured to collect log and history information. This information enables the tracking of approval workflow states, but the patent application does not describe how this can be combined with lifecycle management. Further, the U.S. Pat. No. 8,239,819 B2 titled “Method and system for managing the lifecycle of a service oriented architecture” of applicant and the related European patent 1 898 345 B1 of applicant discloses a method and system for performing complex lifecycle management in SOA registries, but also proposes only options for rejecting or accepting lifecycle transitions. Finally, the US patent application 2011/0314439 A1 titles “Software approval process using service governance” shows how lifecycle management and approvals can be used to automatically deploy SOA assets, such as web services.
However, the prior art approach of providing only the option to reject or accept a requested lifecycle transition makes the approval quite inflexible. For example, when requesting to move an asset into the “In Production” lifecycle state, the approver could generally agree to the requested transition, but may want additional tests to be executed before moving the asset. With the capability of only approving or rejecting the requested transition, the approver has to reject the transition or wait with the approval until the additional tests have been performed. Rejecting the transition, however, does not cover the approver's intention. Moreover, once rejected, the transition has to be requested again later on and the approval process has to be performed again, which wastes processing time and resources. On the other hand, waiting with the approval until the testing has been done also does not cover the intention of the approver. Moreover, the approver has to do the final approval once the testing is completed, which again creates unnecessary waiting times and requires processing resources and time that could be used more productively.
It is therefore the technical problem underlying certain example embodiments to provide an approach for controlling the lifecycle transitions of distributed computing components in a more efficient and flexible, yet secure way, thereby at least partly overcoming the above explained disadvantages of the prior art.
This problem is according to one aspect solved by a lifecycle management system for at least one computing component. In the embodiment of claim 1, the lifecycle management system comprises:    a. means for defining a lifecycle model comprising a plurality of lifecycle states which can be assigned to the at least one computing component;    b. wherein the plurality of lifecycle states comprises a production state and wherein the lifecycle management system ensures that the at least one computing component can be productively used only if it is assigned the production state;    c. means for receiving a lifecycle transition request for assigning a requested target lifecycle state of the lifecycle model to the at least one computing component;    d. means for assigning a conditional lifecycle state to the at least one computing component which is different from the requested target lifecycle state, and for specifying at least one condition that has to be fulfilled in order for the at least one computing component to be assigned the requested target lifecycle state; and    e. means for automatically assigning the requested target lifecycle state to the at least one computing component when the at least one condition is fulfilled.
Accordingly, the embodiment defines a lifecycle management system operating on a lifecycle model which ensures that the managed computing component(s) can only transition from one lifecycle state to the next in a controlled manner. This is achieved in that the lifecycle management system is adapted for interpreting one or more conditions (e.g. defined in one or more policies) assigned to the lifecycle state transitions connecting the lifecycle states and for allowing the assignment of a requested lifecycle state (target lifecycle state) to a computing component only if the respective condition(s) (e.g. defined in the policy/policies) is/are fulfilled. In particular, one of the lifecycle states of the lifecycle model is a productive state (hereinafter also referred to the “In Production” state) and the lifecycle management system ensures that a computing component can only be productively used, i.e. used and/or called by another computing component, if it is assigned the production state.
Certain example embodiments depart from the inflexible approach known from the prior art to provide only the option to either approve or reject a given lifecycle transition request. To this end, the lifecycle management system of certain example embodiments allows what is hereinafter called “conditional approvals”, which involves the ability to choose the target lifecycle state for a requested lifecycle transition and thus makes the lifecycle management more flexible and efficient. Choosing the target lifecycle state may be accomplished by either selecting a target lifecycle state from a plurality of pre-defined potential target lifecycle states (which may be foreseen in the lifecycle model), or by defining a new target lifecycle state (i.e. the lifecycle model is dynamically extended at runtime).
In any case, instead of just accepting or rejecting a requested lifecycle transition, certain example embodiments allow to assign a lifecycle state to the at least one computing component which is different from the requested target lifecycle state. The different lifecycle state is in this context called a conditional lifecycle state and the lifecycle management system allows for specifying at least one condition that has to be fulfilled in order for the at least one computing component to be assigned the requested target lifecycle state.
Accordingly, an approval process executed by means of the inventive lifecycle management system offers the approving user and/or group three options: The “Direct Approval” option follows the requested transaction and moves the asset to the requested lifecycle state. The “Reject” option moves the asset back to the original lifecycle state. The third option involves an additional lifecycle state and defines additional criteria for the computing component to be fulfilled before the requested lifecycle state is assigned. Once this/these condition(s) is/are fulfilled, the lifecycle management system automatically assigns the requested target lifecycle state to the at least one computing component. In summary, this provides for a more flexible and efficient handling of requested lifecycle transitions, while it is still ensured that the computing components only evolve through their lifecycles in a controlled and consistent manner, so that the proper operation of the underlying computing system is ensured.
In one aspect, the lifecycle management system is adapted for automatically deploying the at least one computing component to a productive environment when the at least one computing component is assigned the production state. Accordingly, it is ensured that other computing components cannot use a computing component unless it is present in the productive environment.
In another aspect, the at least one condition is defined in at least one policy and comprises at least one parameter, the value of which can be specified by an approving entity. Accordingly, this aspect provides not only fixed policies but policies that can be parameterized, leading to more flexibility and customizability of the lifecycle management. For example, a testing policy may provide a parameter that allows specifying the tests that have to be executed, and/or a runtime invocation policy may provide a duration parameter for specifying a monitoring time period.
Furthermore, at least one policy associated with the lifecycle transition request may comprise a plurality of conditions, and the lifecycle management system may be adapted for ensuring that the at least one computing component is assigned the requested target lifecycle state, if any of the plurality of conditions is fulfilled, or if all of the plurality of conditions are fulfilled. This is particularly advantageous in case an approval has to be given by a group of users, wherein the decisions of the approving users have to be consolidated. It will be appreciated that the use of policies is optional and that any other equivalent means to define certain conditions is suitable.
Preferably, the lifecycle management system comprises a registry which stores a description of the at least one computing component, wherein the description comprises a lifecycle property which indicates the current lifecycle state of the computing component. Even more preferably, the lifecycle management system further comprises an event channel and a policy engine, wherein the registry is adapted for issuing an event on the event channel indicating a lifecycle transition request for the at least one computing component, and wherein the policy engine is adapted for consuming the event and for processing the lifecycle transition request in accordance with at least one associated policy. Accordingly, the lifecycle management is in this aspect implemented based on the event-driven architecture (EDA) paradigm, which allows for a particularly timely processing of the lifecycle management, as well as for improved extensibility, as will be further explained in the detailed description further below.
In one example, the requested target lifecycle state is the production state, the conditional lifecycle state is an extended testing state and the at least one condition of at least one associated policy specifies at least one test that has to be passed by the computing component before it is assigned the production state. This aspect ensures that computing components are only propagated to the productive state (and become usable by third parties) when all necessary tests have been successfully passed. In addition or alternatively, the requested target lifecycle state may be an out of production state (also referred to as “Retired” state), the conditional lifecycle state may be a retirement pending state, and the at least one condition of at least one associated policy may specify that the computing component can be assigned the out of production state, if it is not invoked for a defined time period. Accordingly, this aspect ensures that a given computing component is only set to “out of production” when it is no longer used by third parties, thereby again ensuring the proper operation of the underlying computing system.
As already mentioned further above, the at least one computing component may be a Service-oriented architecture, SOA, asset, such as a Web service, and/or an Application Programming Interface, API, asset. Also, the lifecycle model may comprise at least one lifecycle state which comprises a plurality of nested lifecycle states. Accordingly, a lifecycle state may be a “lifecycle stage” which in turn comprises multiple lifecycle states, i.e. a lifecycle stage may define a sub-process within the overall lifecycle model.
Certain example embodiments also provide a computer-implemented method for managing the lifecycle of at least one computing component by a lifecycle management system. In the embodiment of claim 11, the method comprises the steps of defining a lifecycle model comprising a plurality of lifecycle states which can be assigned to the at least one computing component, wherein the plurality of lifecycle states comprises a production state and wherein the lifecycle management system ensures that the at least one computing component can be productively used only if it is assigned the production state, receiving a lifecycle transition request for assigning a requested target lifecycle state of the lifecycle model to the at least one computing component, assigning a conditional lifecycle state to the at least one computing component which is different from the requested target lifecycle state, and specifying at least one condition that has to be fulfilled in order for the at least one computing component to be assigned the requested target lifecycle state, and automatically assigning the requested target lifecycle state to the at least one computing component when the at least one condition is fulfilled.
Further advantageous modifications of embodiments of the method are defined in further dependent claims.
Lastly, certain example embodiments also concern a computer program comprising instructions for implementing any of the above-described methods.